\section{Introduzione}\label{introduzione}

Nella progettazione di un sistema distribuito gli aspetti principali da tenere in considerazione sono, per la maggiore, facenti parte dello spettro delle problematiche relative al mantenimento coerente di uno stato globale condiviso, durante tutta la vita del sistema.
\\\\In ambito di giochi distribuiti, lo stato globale rappresenta lo stato attuale del gioco. La variazione ed il conseguente aggiornamento di tale stato è dovuto esclusivamente alle interazioni che gli utenti (da ora \emph{peer}) intrattengono tra loro in base al valore corrente dello stato.
Da qui diventa facile immaginare uno scenario in cui un peer del sistema, in possesso di una versione dello stato differente da quello globale, compie un'azione basandosi su una realtà non vera, propagando ai rimanenti peer uno stato incoerente e compromettendo così le funzionalità e l'avanzamento corretto del gioco.
\\Entro i limiti tracciati dalle specifiche, lo scopo di questo progetto è quello di tollerare situazioni analoghe prodotte da guasti di tipo crash e garantire la continuità del servizio.
\\Infatti, le specifiche prevedono la realizzazione di un'infrastruttura di gestione dei guasti basata sul coordinamento dei processi in gioco mediante invocazioni remote (RMI).
\\\\Comunemente le procedure di coordinamento vengono effettuate ad ogni azione di gioco, in modo tale che lo stato venga aggiornato e propagato, a tutti i nodi che compongono il sistema, al verificarsi di ogni evento rilevante ai fini del gioco.
\\Assunto questo, uno degli aspetti che ha catturato la nostra attenzione e a cui abbiamo dato molta enfasi progettuale, riguarda il costo relativo all'overhead prodotto dalle procedure di gestione. Supponiamo infatti che tale overhead dipenda strettamente dalle caratteristiche del gioco (e.g. \emph{numero di giocatori, frequenza di aggiornamento, azioni rilevanti}) e dalla logica di interazione (\emph{a turno o concorrente}).
\\\\L'obiettivo principale a cui aspiriamo è infatti limitare il numero di invocazioni remote relative ai meccanismi di \emph{fault tollerance}, in condizioni normali adottando un approccio ottimistico, mentre in casi di \emph{failure detection} dando ad ogni singolo peer la possibilità di auto-gestire il guasto (\emph{self-managed peer}) evitando uno scambio di dati superfluo. L'approfondimento di tali aspetti verrà trattato nella sezione \ref{aspettiProgettuali} relativa alle scelte progettuali.
\\Dal punto di vista implementativo invece, sempre nell'ottica di limitare il numero di invocazioni remote tra i processi in gioco, abbiamo scartato a priori le soluzioni che comprendono l'implementazione di un ``livello di rete'' generico e completamente indipendente dall'applicazione sovrastante. Infatti, al costo di una logica applicativa più complessa, articolata e accoppiata all'infrastruttura di tolleranza, abbiamo diminuito il numero dei messaggi scambiati, mostrandoci semplicemente più flessibili rispetto alla natura e alle caratteristiche del gioco scelto. Si rimanda alla sezione \ref{aspettiImplementativi} dove tali argomenti verranno trattati in maniera più dettagliata.
\\Infine nelle rimanenti sezioni, \ref{valutazione} e \ref{conclusioni}, verranno evidenziati gli aspetti di convergenza e divergenza con le soluzioni proposte dallo stato dell'arte attuale e alcuni aspetti migliorabili a partire dall'applicazione fino al protocollo di gestione dei guasti.